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Subject* More on Protection Auditing 

The design review of MTB-103 ("The Protection Auait Mecnanisms 
for Multics-") raised several issues that requirea further study. 
Most of the concerns expressed dealt with the performance impact 
of protection auditing, particularly in installations not using 
auditing ana/or the access isolation mechanisms. This memo gives 

ImhJV? 1 " details concerning the expected performance cost of 
auditing, ana re-visits several other design issues. 

LQ^atl^4-Si^jL,aiKL±jta£uJJ^D_Cost of Aucntfng_Call5 

Potentially auaitable directory control events and faults (those 
wnich require a test to see if auditing is necessary) occur on 
tne order of a times a second. Thus, is it important to minimize 
the number, code size, and execution cost of conditional 
sequences and calls for auditing in these areas. The following 
performance-sensitive modules will contain auditing calls in the 
initial implementation. 

oir_control_error - All directory control programs (should) call 
J^ qt ^ n J process has insufficient access to complete some 
operation. A 3-mstruction conditional and a 14-instruction 
audit call will be inserted just before the return, to audit 
instances of denied access. 

fim - Some slight restructuring and a conditional audit call are 
necessary to audit illegal procedure faults (not including 
legal bib instructions or out-of -bounds) and access violation 
faults (not including ring alarms, out-of-bounos, or illegal 
ring order). Audit checking and calling sequence aods about 30 
instructions to fim. 

Current plans for a second-stage implementation will involve 
audit sequences in two additional performance-sensitive modules. 

makeknown - rmen the proposed KST changes (Mlfc-104) are 
implemented, access information in the KST will make it 
possible to audit successful initiations of protected segments 
and directories (those with access class greater tnan 
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system-low) In makeicnown. At the point where a segment or 
directory is actually aaoed to the KST, about 60 instructions 
of auditing coue will be inserted. Tne auditing of successful 
making known of protected directories, normal protected 
segments, and "system" (ring I multi-class) segments will be 
governed by separate auoit select flags. For segments with 
system-low access class, a 3- instruction test will skip the 
auditing code. 

find_ - innen the recursive making Known of parent directories 
fails due to insufficient authorization to search further, it 
is desirable to log the full pathname of the segment. At 
present, find_ is not structured well enough to do this 
conveniently. A re-write of f i no_ will allow this type of 
auditing, and will probably result in a worthwhile improvement 
in system performance. 

It is expected that, in a system not performing any auditing, the 
execution cost of the additional auditing checks will be arouno 
20 instructions/second, quite negligible. 

Performance Costs of Au Qiting 

An actual auditing call represents somewhere between bOO and I OUu 
instructions, including the call to protection_auoit_, the calls 
it makes to acquire all the information neeoed for the log, the 
call to syserr, and the later invocation of syserr_locger to copy 
tne syserr wired buffer into a paged buffer. Thus, in normal 
system operation (i.e., no user purposely generating extra 
auditable protection events), auditing of all protection events 
for all processes can represent as much as about 5 milliseconds 
overhead per second of real time. This is a significant cost, 
but is not unreasonable if one bears in mind that only 
installations using auditing will pay this cost. 

Given the cost of .5 - 1 millisecond per audit iog entry, it is 
possible for a user to cause a great deal of system overhead by 
repeatedly causing auditable protection events. In installations 
wishing to detect "penetration 1 ' attempts, this overhead will 
certainly be justified. Future enhancements of protection 
auditing will probably include detection of significantly 
abnormal auditing frequency, probably with an 
exponentially-weighted per-process auditing frequency meter in 
the pds . 

Message Segment Auditing 

The new message segment design (see MlB-101) marks message 
segments as "multi-class" because they may contain messages of 
many access classes, ano assigns the message segment itself a 
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class equal to the highest class of message it can contain, 
because message segments are manipulated only by ring I 
primitives, and because the actual protected objects are the 
individual messages themselves, initiations of message segments 
are not very interesting security events. The eventual neea is 
for some finer-grained auditing of the use of message segments. 
Io prevent flooaing of the syserr auait log with innocuous 
messages for dprint and absentee request submissions, a separate 
pds audit select flag will control the auditing of ring 1 
multiple class segment initiations. maketcnown will checK for 
tnis case when determining whether to audit the initiation of a 
protected segment. This allows initiations of normal protected 
segments to be audited without requiring "system segment" 
initiations to be audited. 

Audit selectivity Classes 

Mainly for performance reasons, the auait selectivity classes 
defined in Mrb-103 have been redefined. There are two groups of 
flags (in the left and right 16 bits of a word in tne pas), one 
group for events audited directly in ring 0, and one group for 
events audited via a gate from ring I. 

rina audit selfirUyj f,Y clflSffftff. 1 

- initiations of protected non-airectory segments ( tnose witn 
access class greater than system-low), not including ring 1 
multi-class segments 

- ma King known of protected directories (These are separated 
out because many directories may be maae Known as 
by-proaucts of other operations. Knowledge of the maKing 
Known of a protected directory is generally of less 
importance than the initiation of a protected non-airectory 
segment. ) 

- initiations of ring I multi-class segments 

- access denied to any segment or directory oue to improper 
authorization, ACL mode, or ring validation level 

- ring-relateo access violation faults (except ring alarms ano 
illegal ring orders) 

- ACL mode related access violation faults (except 
out-of-bounos) 

- illegal procedure faults (except legal HIS faults and 
out-of-bounds) 
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- attempted IPC send-downs 

- assignment of system privileges to a process (eitner blanket 
privileges, or privileged initiation of single segments) 

- rejected device attachments (tape ana aisk arives) 

- protection relatea actions of the SSA (performed by ring 
primitives) sucn as segment downgrading ano turning off 
security-out-of-service 

rina-J audit selectivity classes' 

- rejected media (tape and disk) mounts 

- message segment protection events (such as overflows) 

p_exzi£am£iLt_AufljLi_i£i£c.iiy_iiy 

being able to audit the use and attempted misuse of specific 
segments for all processes allows the use of selected protected 
information to be monitored without requiring the auditing of all 
use and attempted misuse of all protected information for all 
processes. 

ine initial design of this capability used a bit in the brancn to 
cause auditing on all initiations, access denials, ana access 
violation and illegal procedure faults. Tne cost of cnecninc a 
bit in the brancn during fault processing is far too nign for tne 
marginal value of auditing such faults, so no per-segment 
auuiting will be uone on faults. 

As per-segment auait flags will change infrequently, ana since 
such cnanges will not need to become effective immediately, tnis 
flag can. oe copied into the KSi entry when the segment is maue 
known, to save directory locking. 

As per-segment audit selectivity is not an immediate necessity, 
tne only change will be to reserve a bit in tne branch ano a bit 
in the KSi. 



&i££££iuc„tLLaj3s. 

To provide concrete data on questions of protection auditing 
performance, some meters will be addeo: 

1 suits. - Mo one seems to have any good idea of the frequencies of 
various Kinos of faults. A simple aos instruction in fim will 
provide a histogram of faults that reach fim. Ihe nistogram will 
go into the unuseo space in wi reo_hardcore_data. Inese meters 
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may not be permanent. 

a udit i ng ChfiCKS . - Some temporary meters will be useful to 
determine how often audit checks are made. At each place wnere 
an audit select flag is checked in rina 0, a counter in 
active_nardcore_oata will be updated. Since tnese meters will 
definitely reference an additional page each time an audit flag 
is checked, tney will not be permanent. 

auai t i nq UrnS -and P a gi ng - Some permanent meters maintained by 
protection_audit_ will record in active_hardcore_data the average 
time and page faults spent logging audit messages. 
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